A central processing unit (CPU), or sometimes simply processor, is the component in a digital computer that interprets instructions and processes data contained in computer programs. The fundamental operation of most CPUs, regardless of the physical form they take, is to execute a sequence of stored instructions called a program. An operating system (OS) is a software program that manages the hardware and software resources of a computer. The OS performs basic tasks, such as controlling and allocating memory, prioritizing the execution of programs, controlling input and output devices, providing network access, and managing files.
A software instance is an application program running on an embedded computer system. Typically a software instance will include the application code and the operating system code built together as a single executable image sharing all the computer memory and hardware resources.
In a multi-tasking program, there are independent sequences of code (threads) which execute asynchronously with respect to each other. In such programs, an operating system service, called a thread scheduler, provides the mechanism for selecting which of the threads to run. Multi-tasking programs are further divided into two groups: preemptive systems in which control of the scheduling mechanism is based on asynchronous external events, such as a timer interrupt; and cooperative systems in which control of the scheduling mechanism is determined by the threads in the program itself.
To execute more than one software instance on a computer system, the following three problems have to be solved:                1. Each software instance must have an isolated address space from the other instances. This is accomplished using the MMU to provide a logical address space for each instance. A MMU defines a mapping between logical addresses and physical addresses. In one typical design, the logical address space is divided into fixed size units called “pages” and the mapping is defined by a set of “page tables”.        2. Each software instance must be able to access all of the hardware resources, such as I/O devices, that it requires for its operation, including any interrupts that are defined by the underlying hardware. The invention does not resolve the problem of simultaneous access to the same hardware by different instances.        3. There must be a mechanism for selecting which software instance to run and switching the execution environment between different instances on the computer system. This mechanism is performed by an “instance scheduler”. Swapping instances requires saving the state of the execution environment, called a code context and restoring the code context of the next software instance to run.        
Previous methods of running more than one instance on a computer system included virtualization. Virtualization works by providing a hardware abstraction layer, which can be either complete or partial. The XEN™ virtual machine, available from XenSource Inc., enables the execution of multiple guest operating systems on the same computer hardware. This form of virtualization is achieved using a technique called paravirtualization. In paravirtualization, a software interface is presented to a virtual machine that is similar but not identical to that of the underlying hardware. Presenting the software instance to the virtual machine requires the OS to be explicitly ported to run on top of the virtual machine, but may enable the virtual machine itself to be simpler and the virtual machines that run on it to achieve higher performance.
Emulation is another method of running more than one instance on a computer system. A software emulator allows computer programs to run on a platform other than the one for which they were originally compiled and linked. The BOCHS emulator, available from <http://bochs.sourceforge.net/> and sponsored by Mandrakesoft, a French company now known as Mandriva, can emulate the hardware needed by the guest operating system, including hard drives, CD drives, and floppy drives. Disk and ISO images can be “inserted” while the system is being run. However, the system performance is very slow due to the fact that the emulation must completely simulate the CPU instruction set. Additionally, emulation doesn't provide any hardware virtualization features.
Interrupts handling is more complicated on a system including more than one CPU. This is necessary because each of the CPUs can access the same set of hardware resources. Theoretically, anytime a resource generates an interrupt, the resource has to direct the interrupt to the proper CPU. One way to ensure that the interrupt gets to the proper CPU is to split up the hardware on a system so that any given instance running on the associated CPU is limited to the associated resources and associated interrupts. Thus, an interrupt only affects the single associated CPU. Problems remain, however, if the CPU runs more than one instance.
Currently, when an interrupt is generated and there is only one instance running on a CPU, interrupt dispatch code handles the interrupt directly. An instance registers its associated interrupt service routine (ISR) for each interrupt it receives. Each ISR has an associated interrupt and code context. When a CPU receives an interrupt, it saves the current context, runs the ISR in it's own context, and then restores the saved context. When multiple instances exist, each instance can register its own interrupt service routine for an interrupt. The instance running on the CPU when the interrupt is received may not be one of the instances that registered an ISR for the particular interrupt. In this case, instance swapping may be necessary so the appropriate ISR's can be invoked.